Integrated circuit (IC) designers commonly describe their electronic circuit designs in HDL (hardware description language) such as Verilog, VHDL, SystemC, etc. VHDL stands for VHSIC (very high speed integrated circuits) hardware description language. Designs are usually simulated with test programs. When the simulation results are not as desired, debugging may be performed to find the errors. Generally, the errors may exist either in the design code or in the test program code.
To debug the design code, simulation tools typically store signal values during the simulation in a file that may be referred to as a ‘dump file’. Using the dump file, users, such as designers, usually have a good chance to locate and fix the errors in the design code. However, if the errors are in the test program, the signal values that are stored in the dump file may not sufficient, for example, because the dump file generally includes data sampled once for every clock cycle of the synchronous simulation. Test programs, however, are asynchronous, and often include variables that change value, for example, multiple times while the clock cycle of the simulation time stays unchanged. This may occur, for example, if the test program is performing calculations to determine what signals to provide the design code during a next simulation clock cycle. In addition, test programs can create or delete variables dynamically. As a result of these software behaviors in the test programs, traditional synchronous dump-file-based debugging may not be very useful for debugging test programs.
Consequently, interactive debugging (analogous to running “gdb” for software debugging) is typically used for debugging test programs. During interactive debugging, a simulation is run, during which, like non-interactive simulations, the test program code is executed such that the design code is exercised and tested. In addition, unlike non-interactive simulations, during interactive debugging, the test program code may be temporarily suspended, for example, using breakpoints. While suspended, the user may, for example, query or change variable information from the test program code and may query or change signal information from the design code.
There are times when users are not sure if an error is in the design code or in the test program code. Therefore, during interactive debugging, users may also cause the simulator to dump signal value changes into a file. This enables the designers to simultaneously debug the test program code and the design code. Unfortunately, dumping values in the file can dramatically slow down the simulator, can be in a cumbersome format, and may require unreasonable amounts of data. So the designers are constantly caught in a dilemma: should they bear with the slowness and cause interactive simulation to store information corresponding to a large number of variables and signals in a file so that in case the error is in the design code, there are enough stored data for debugging; or should they seek low simulation time and cause the interactive simulation to store little variable and signal information and accept the risk of not having enough data for debugging, for example, if the error is in the test program code?
What is needed is a method for users to perform interactive debugging efficiently, without the need for storing excessive variable information of the test program and/or design. There is a need in the art for an efficient system and method for debugging hardware description language design code and test program code simultaneously.